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This evaluation sumiTiari zes old: present knov;ledge of HP's System/ 
3000, a new entry into the $100K--300K computation marketplace. 
Information has come in from several sources, including the 
public showing at FJCC, so the evaluation should be accurate. 

1. History of the Product 

The 3000 probably had its hardweire roots in the legendary HP 
OMEGA, supposedly a 32-bit edp machine that the company developed 
at great expense, then canned at the last minute. We know 
nothing specific about the OMEGA, but if it did have an. edp orien- 
tation; HP probably had a COBOL project going. If an OMEGA COBOL 
was developed, it might show uj:* on the 3 000 some day. 

Ex-Burroughs people were apparently involved in the design of the 
OMEGA, and almost certainly in the design of the 3000. HP as a 
company has clearly swung to the Burroughs higher level language 
orientation. Even on the 21,14, 2115, 2116 series, they con- 
centrated on building good highei: level languages, and succeeded. 
Their language processors are the best in the small computer 
industry. These include a 16 and 3 2-user BA3IC, a FORTRAN IV 
and an ALGOL, all powerful and all rock solid. They also devel- 
oped a disk operating system and a real-time operating system 
that are very competitive. 

This approach has had good market acceptance, especially with 
the bigger systems. The time-sharing system in particular has 
demonstrated a market for ci reliaible, no-frills production system 
that is simple to use even at $90~130K a shot. The good pro- 
duction languages justify the cost. The smaller, single-user 
systems are well liked, too, but here cost has been much more of 
a factor. Customers take the lowest cost system, even if it's a 
little more complex to use and urogram. DEC has used its price 
advantage to chew them up here„ 



Dick Clayton -2- December 9, 1971 



With this market orientation, t^ie 2116 hardware must have been 
a source of enormous frustration. HP has done best in the $100K+, 
higher level language market for which their cpu was not de- 
signed. They have been getting killed in the small system and 
OEM business for which it was designed. As of a year ago, there 
was no competition (v/ell, maybe the Honeyv^ell 1640' s) for the 
former market, but brutal competition down below. 

HP had to follow their succc-ss in the sub~PDP-10 production com- 
puting market. It was only natural for uhem to develop new 
hardware specifically for this maricet. This they have done with 
the System/3000. 

2. The System/3000 Product Concept 
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HP has specified a production cciupiiting system to sell for between 
$100K and $300K, Because it will be used for production computing, 
it is totally based on higher level languages; in this case BASIC 
and FORTRAN. Because it is production oriented, it includes a 
batch processing system.. It also, of course, includes time- 
sharing terminal operation. Finally, it offers real-tim.e capa- 
bility, although this v/ill probably ireceive less emphasis. It 
will, however, be good enough to allow HP to bring their instru- 
mentation capabilities into the sales situation. 

They have opted for a single operating system to service all three 
functions simultaneously. TOPS- 10 proves the viability of this 
approach— "the three functions sha.re many common characteristics, 
thus cutting down on total impieroentation. More important, it 
allows the individual user to use whichever mode of operation best 
suits his need. Programs developed in one mode may be used in 
either of the other tv/o. 

Finally, they have designed hardware specifically for this one 
system. Because the system will be used almost exclusively to 
run higher level languages, the order code has been designed to 
do that efficiently. There are lots of stack operations, for 
example, and no general registers. Because it will always be 
used in a multi-programmxRg mod?, mcimory addressing and executive 
protection have been optimised for this purpose. And finally, 
because they have a whale of a lot of systems programming to do, 
they have designed an imp lenient -it ion language to do it in. 
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In short, the whole system is designed from the ground up to be 
a production computing system and nothing else. Nowhere in their 
promotional material ar€i they emphasizing the new cpu, for 
example. It is not the pioduct„ The product is the computation 
system . HP is not going after the hardv/are market. (Just for 
the record, it's a 16-bit cpu. This fact does not show up in 
most HP literature.) 

3. The 3000 Multi-Pro qramm.ing Execut ive ( MPE ) System 

MPE is what holds System/'3000 together „ It seems to be a straight- 
forward design which will probably end up looking like TOPS- 10 on 
the inside. HP claims that the resident portion of Monitor will 
be under 5K. They point to thci efficiency of the instruction set 
(instructions are 8 or 16 bits) in backing up this claim. 
However, the instruction set xs optimized more around compilers 
than executives, so it may not pan out. (On the other hand, their 
BASIC time-shared exec plus the language interpreter on the 2116 
fits in 9K, versus 18-20K for RSTS . ) Program size on the 3000 
will be very critical fsince they now have: a 64K limit on memory. 

All other Exec functions v^ill be swappable, as will the user pro- 
grams. Code is stored in pure segments, each of which is variable 
in size, up to 16K, Prograras may consj.sc. of more than one 
segment, but there is a system limit of 256 total code segments. 
Each segment is logically separate and self-contained . Therefore, 
even a mu It i~ segment progrcim nt3€?d only have one segment in core 
at a time. There are hardware .instructions for procedure calls 
as well as subroutine calls. Proeedure calls can probably cross 
segment boundaries while subroutine calls cannot. It is not 
clear how much of an external procedure call is implemented in 
hardware. Obviously, since the code segments are pure, they need 
never be swapped out. The are simply overlaid. 

All user program data is stored in a single data segment, which 
is also variable in size, up to 32Ko Assumed ly, the exec also 
has a data segment. These segments are relocatable, so memory 
management seems to be relatively clean,. There is room in a 64K 
system for the 5K resident exec, IIK of swappable exec, plus a 
16K user code segment and a 32K user data segment. If user 
segments are smaller, several aa.ii be resident at a time. But 
there is the possibility of real swapping bottlenecks if too many 
users are using big da tat segments « 



Dick Clayton -4- December 9, 1971 



The core layout is consistent with the philosophy of the 2000A 
time-sharing BASIC system. It made no attempt to keep multiple 
users in core, relying instead on a very high speed swapping 
device to prevent bottlenecks. Again on the 3000, the 64K core 
limit means that a big job can hog the whole core. Their 
swapping store transfers a IG-bit v/ord every 4+ microseconds, 
but even this high speed won't save them if user areas get big. 
The viability of the system de^pends on the ability of the com- 
pilers to produce tight code and thus keep the user areas small. 

The l/O structure of che hardware is no prizewinner, but it 
appears to be good enough.. It will not be a significant bottle- 
neck in the overall production system they are selling. It is 
enough to handle their disks and tapes, and everything else on 
the system is relative Iv low speed. It is not clear how easy 
it is to program devices, but this would only be a problem if 
the handler's get big. 

The system has the peripherciis it needs to get the job done. 
High-speed disks and big disk pa,ckJ3 should take care of swapping 
and file needs. HP's 1600 BPI tapes are more than good enough. 
They have good card equipment and an adequate line printer (600 
lines a minute). One problem area may be terminals. They 
obviously realize they cannot go to this marketplace with 
Teletypes, so they're talking Datapoints and a new 30 cps hard 
copy terminal. The^y will have tc succeed in producing these 
terminals at a good price to stay viable since term.inal costs 
alone on a system like this can exceed $100K. 

There are no details yet on the file implementation of the system, 
Multi-pack disk file systems are a problem for any 16-bit machine 
and probably will he here as well» Resource sharing for other 
peripherals is claimed but there are no details. Spooled batch 
input and output is claimed. 

Another area where there is no concrete information is the system 
command language. There is every reason to believe, however, 
that it will stress simplicity of use. This was a key selling 
feature of the 2000 series. Since it is noc a general purpose 
systemi, it obviates the need for the kind oc complex command 
syntax that has frequently plagued PDP-10. Emphasis will be on 
doing the common production tasks simply rather than trying to 
do everything. Since users do have access to the implementation 
language, HP does have an answer to those who want to do more 

eccentric things. 
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4. The Language Proce ssors 

Languages are the key to System/3000 ' s success, so the quality 
of the language processors is critical. Right now, they offer 
FORTRAN, BASIC and an iraplementation language. The specs on all 
of them are good. 

The FORTRAN is standard ANSI FORTRAN, with an intelligent set of 
extensions. String handling is beefed up and seemingly complete 
file capability has been added. The ability to have 99 files 
open at a time seems adequate. Terminal oriented l/O has been 
added, as would be expected. Customers don't usually play the 
features game too much with FORTRAN. Either it is full FORTRAN 
IV or it ain't. This one is, so it's probably adequate. The 
big competitive question will be its speed. 

BASIC is a language where the features game does get played, and 
HP has beefed up their language accordingly. They have closed 
the gap to RSTS by adding integers, double precision, lots of 
new string stuff, output formatting, and better files o (They 
seem to have missed virtual arrays,) Their BASIC (which is 
interpretive) is not as good a production language as RSTS, but 
the availability of FORTRAN probably makes this insignificant. 

There are no details on whcit the implem.entat ion language (SPL) 
looks like. But its usability as an on-line language matters 
very little. The mtiin question about SPL is whether it will 
support the building on good language processors and a good exec. 
There is no way of telling this yet. Obscure SPL bugs could 
wreak havoc on the development c^ffort. Desi.gn mistakes could 
cause the code to get big« These are serious problems with a 
technology as new as implementc?J:ion languagcjs. Burroughs seems 
to have mastered it, but no one else has committed to it the way 
HP now has . 

The question remains: how big v^ill these l<inguage processors be, 
how tight will their output be, and how fast will it run? If 
any of these parameters gets out of control it will seriously 
degrade system performance by jacking up the swapping load. 
Right now, though, we have to assume that: tliey will solve these 
problems. The order code is clearly optimi.'2ed for compiler 
output, so it should be tight code. HP has good compilers now, 
so they know how to build them. It is impossible to predict 
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execution time at this point. They have no general registers 
and they have no solid state memories. An 11/45 compiler that 
makes good use of both these features should be significantly 
faster, but we still have to build that compiler. 

Another factor that impacts throughput is the computation hard- 
ware. Hardware floating point is 32-bit only. They will probably 
implement 48-bit formats in software, averaging about 1000 micro- 
seconds per operation. Theoretically, they can add better 
floating point at any time (same is true of solid-state memory) 
but their engineering staff is undoubtedly over-committed now, 
and will be for some time to come., They'll do it, but not soon. 

5. The Implementat i on Sch edule 

A product announcement as sweeping as System/SOOO brings us back 
to the early Sigma 7 days. Can they pull it off and, if so, how 
soon? They are quoting delivery in a year. They had no software 
to show at FJCC. 

First, it is clear that HP understands each of the components of 
the system, with the possible exception of the implementation 
language. They have built fast, tight language processors for 
both BASIC and FORTRAN. (They also have a very good ALGOL.) 
They have a time-sharing system, a batch system, and a real-time 
system. And they know what it takes to shake down software 
because they've brought each one of these packages to a rock- 
solid level of reliability. 

Implementation language is the only component they've never done 
before. (If they do have ex-Burroughs people, they've picked up 
experience that way.) They are banking on it heavily. They are 
confident that it v/ill allow them to develop their software 
three to six times faster and they're quoting software deliveries 
on this basis. It is not clear that this confidence is well 
placed. If there are problems in the implementation language 
itself, or undetected bugs in the SPL translator itself, they 
could find it taking longer to aet their code written. A prudent 
guess would be that the implementation langiaage will help some, 
but not as much as they're banking on. Software will be late, 
and will be flaky at first. 
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A far bigger potential problem is HP's lack of experience in 
multi-function systems. They've built a batch system, a real- 
time system, and a time- sharing system, each with one language 
at a time. Conceptually, it's easy to put them all together 
into one system, but everyone who does it finds it's harder than 
they thought. This is HP ^ s first go at anything like a general 
purpose, multi-function operating system. They are bound to run 
into unexpected problems. 

I think they have the talent and the determination to beat these 
problems eventually. They may (and probably will) be late, but 
they will get there. The company has invested heavily in this 
project. They will see it through. 

6. Marketing Strategy 

HP is already selling the System/SOOO very hard, even at the 
expense of 2100 sales » They pushed it even before introduction, 
when they had zero to show. Interestingly enough, they have 
announced the BASIC time-sharing systems on the 2100 cpu (dubbed 
the 2000E for 16 users, the 2000F for 32) but have made no real 
noise about them. At $49K, the 16 user 2000E is a significant 
product that undersells both RSTS and TS-E. The fact that they 
let its introduction he completely overshadowed by the 3000 series 
suggests that they switched the selling effort to the 3000 now. 

If so, they will undoubtedly convert their whole computer sales 
force into System/3000 specialists with each individual salesman 
having a market specialty. They will clearly take dead aim at 
the education market where they did $5 million in sales last 
year. They have a trained education sales force, a good reputa- 
tion, and a product that will appeal to small colleges and 
departments within universities. 

System/3000 salesmen will also follow the company's imstrumentation 
salesmen into large industrial accounts „ They are undoubtedly 
looking for sales in the in-^house scientific market. Their success 
here is less well assured. They tried a year and a half ago to get 
into this market with trie 2000A, even offering a 6-month trial. 
They didn't get any takers according to Alex Lakatos, an HP sales- 
man hired into tha Parsippany office. 
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In other markets, they may have to wait till they can demonstrate 
what they say they've got. This v;ill be a problem everywhere, 
but HP salesmen can bridge the credibility gap somewhat by point- 
ing to their reputation for building reliable systems. The 2000E 
and 2000F may be a real hooker here, too. HP also announced month- 
by-month rental terms for these machines » They may be planning 
to sell customers on taking a 2000E until the System/3000 arrives. 

7. dec's Strategy v e rsus System /3000 

I doubt that we will have much luck simply bad-mouthing the 
System/3000. The spec is excellent; if it does what they say it 
will do, it is a very nice product, I also doubt that we can 
get away with simply saying that they'll never get it to run. 
They have too much quality software to point to. 

We'll have better luclc pointing to the fact that they will be 
late delivering the product. The precedents are unanimous — you 
don't get a system like this up on schedule. We can also point 
out that HP is spread dangerously thin on this project. Their 
computer division isn^'t that big, and the rest of the company 
can't help much at all. In this kind of a situation, minor 
problems often turn into major and disastrous delays because no 
one is free to work on them. 

Finally, and most importantly, until they get everything working, 
they have nothing working. The whole system is based on an in- 
tegrated design with many, many interdependent components. If 
they are having problems with time-^-sliaring or real-time, the 
customer can't even limp along with batch because they're all 
interconnected, DEC, on the other hand, already has proven 11 
Family software to build on, Hl> may counter with monthly rentals 
of the 2000E, but that doesn't really solve the problem. 

HP is stretched very thin on a major multi-function monitor system 
(which they've never done before) that requires all components to 
be done and debugged before any components are usable. The 
potential for disastrous delay is so great that customers should 
hold off any commitments, if not avoid System/3000 altogether. 
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